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BACKGROUND 

Field of the Invention 

The present invention relates to the transmission of electronic messages over computer 
networks, and more particularly, to a method and apparatus for managing and manipulating a 
plurality of electronic messages on the basis of pre-determined criteria. 

Background of the Invention 

During the past decade, electronic mail messages ("email") have become an 
indispensable tool for facilitating business and personal communications. Through computer 
networking systems such as local-area networks ("LAN"), wide-area networks ("WAN"), and 
the world-wide web ("WWW"), network users can send and receive notes, messages, letters, 
etc., to communicate with others who are in the same office or perhaps in remote locations across 
the world. 

For a variety of reasons, many email users typically maintain email accounts with 
multiple email service providers. For example, a user may have a business email account, a 
personal email account with a paid service provider, and a personal email account with a free 
email service provider. Moreover, users may have email accoxmts for use with interactive paging 
systems or other handheld electronic messaging devices (e.g., personal data advisor, wireless 
telephone, etc.). Typically, each email service provider will assign a unique email address to 
each subscriber of the service. The email address generally corresponds to the user's account on 
a email host managed by the service provider. As known in the art, one or more email hosts may 
be used to process inbound email while one or more different email hosts may be used to process 
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outbound email. Alternatively, the same hosts could be used for processing both inbound and 
outbound email messages. In the present example, although only a single email host is shown 
for each network, it is to be understood that multiple email hosts may be used in actual 
implementation of an email network. 

Figure 1 shows examples of common service providers typically employed by email 
users for sending and receiving email. For example, the user may have one or more accounts 
with one or more email service providers directly connected to Internet email network 10, such 
as e.g., a service provided via email host 12. Such accounts are generally accessible via any 
computer or network in communication with Internet email network 10. Computers on Internet 
email network 10, e.g., email host 12 or computer 14, may be in communication with each other 
and with computers on other networks, such as Internet Service Provider ("ISP") network 20, 
wireless network 30, interactive paging network 40, or private network 50. Some email service 
providers offer purely Internet-based email services. Such services are accessible to subscribers 
already having connectivity to the Internet. For example, a user on computer 14, already 
connected to Internet email network 10, may subscribe to email services hosted on email host 12, 
The user in this case may be assigned an email address such as: john@emailhostl2.com. In 
addition to using computer 14, the user may access his or her email via other computers, such as, 
e.g., computers 24 or 54 shown in Figure 1. Typical examples of such Internet-based email 
service providers include, e.g., Hotmail.com, Yahoo.com, and the like. 

As noted above, the user may have multiple email accounts through multiple service 
providers. For example, in addition to the accoimt on email host 12, the user may have an email 
account on email host 22 on ISP network 20. In the present example, the user may be assigned 
an email address such asjohn@emailhost22.net. As with the Internet-based email services, 



email services provided by ISPs are generally accessible from any computer on the Internet. For 
example, the user may access email via computer 24, connected to ISP network 20, or via 
computers 14 or 54 on Internet email network 10 and private network 50, respectively. 

As shown in Figure 1 , the user may have more specialized email accounts delivered via 
5 Other networks. For example, the user may send and receive email via wireless network 30 and 
email host 32. Wireless devices, e.g., telephone 34 or personal digital assistant ("PDA") 36, may 
be used to send and receive email to or from other wireless devices on wireless network 30 or 
other email systems connected via Internet email network 10. The user may also have an email 
account on interactive paging network 40 and associated email host 42. The user in this case 

10 may use interactive pager 44 to send and receive email to any other Internet email address. 

Finally, the user may have an email account on private network 50 hosted on email host 52. The 
email service provider in this case could be, e.g., the user's employer and the email messaging 
system hosted on email host 52 could be a proprietary email application server. Moreover, email 
accounts hosted on email host 52 may only be accessible using a computer directly connected to 

15 private network 50 and may require a proprietary client application running on computer 54. 

Users typically are assigned different email address for each individual email account. 
For example the user may have email addresses: jdoe@emailhost32.wireless.com, 
jdoe@emailhost42.paging.net, andjohn_doe@emailhost52.work.com corresponding to v^reless 
network 30, interactive paging network 40 and private network 50, respectively. As described 

20 more fully below, such specialized email services typically are not accessible from any computer 
on the Internet. 

A problem for users having such multiple email accounts is that there may be different 
hardware, software and communications systems requirements for accessing the email stored on 
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each account. For example, some email service providers allow users to access their email via 
any computer connected to the Internet using a variety of suitable email client programs. 
Suitable client programs may include w^eb brov^ser client applications, such as applications 
available from Microsoft Corporation or Netscape Corporation, or other applications using 
5 suitable email communications protocols. Commonly used email communications protocols 
include, e.g., Post Office Protocol ("POP" or "P0P3") or Internet Message Access Protocol 
("IMAP" or "IMAP4"). Other email service providers, may require proprietary software such as, 
e.g., Lotus Notes, or Group vdse. In addition to different software requirements, there may be 
other barriers for managing and accessing email on multiple accounts using a single interface. 

10 For example, private networks may allow access to email services only via certain 

communications channels, such as, e.g., a direct dial-up network connection to a private network 
comprising the email host, or only from computers within a defined physical perimeter. Also, an 
email service provider may only offer access to email accounts via special hardware, such as a 
wireless telephone or interactive pager. 

1 5 A problem therefore exists for users having multiple email accounts because access to 

each email account using a single device may not be possible. One method used to get around 
this problem has been to set up automatic forwarding procedures from each account to a central 
account. Using this method, the user need only ensure access is available to this central accoimt 
to have access to all of his or her email. This method has numerous drawbacks, e.g., there is 

20 little or no segregation of the user's email making it more difficult to separate work accounts 

from personal accounts; depending on the account used to receive all email, attachments may not 
be readable; and in some cases, the user is identified as the sender of the email making it more 
difficult to identify and prioritize the email. Another drawback is that the user must have access 
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to the central account any time he or she wishes to review email messages. However, users may 
not always know in advance where they will be located and what type of email access will be 
available. 

SUMMARY OF THE INVENTION 

The present invention comprises a system and method for remotely managing email 
messages on a source server. The system comprises a database of destination email addresses 
corresponding to subscriber accounts authorized to remotely manage email messages. To 
remotely manage email on the source server, the subscriber (also referred to herein as the "user") 
sends management instructions via email messages transmitted to the source server from one of 
the subscriber's destination email addresses. Accordingly, the instruction email messages have a 
valid destination email address in the message sender-id field. The instruction email message 
may have a special code in some predetermined field, or, alternatively, the instruction email 
message may be addressed to a special account on the subscriber's source server. When the 
source server receives an instruction email message (identified by the special code or because it 
was addressed to a special account), the source server checks the database to verify the 
destination email address as an authorized account. If the destination address is valid, i.e., the 
address has been registered, the source server source server interprets the subscriber's 
instructions and performs the requested management tasks on email in the user's account on the 
source server. 

The instruction message may contain a command providing the user's instructions to the 
source server. Alternatively, if the message contains no command, the source server may 
perform a default action on the user's email messages. The instruction message may further 
include criteria for identifying the email messages to be operated on by the source server. The 
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criteria may include boolean operators and provide conditions or rules for determining whether 
or not a message is to be included. The criteria may also include strings of data and associated 
email message fields which should be searched for matching email messages. Accordingly, the 
user can specify^ with some particularity, which messages in his or her email account on the 
5 source server will be managed. The email managed according to the present invention may 
comprise email messages in the user's inbox, the user's outbox or both mailboxes on the source 
server. 

In a preferred embodiment of the present invention, a registration module and database 
are provided for administering users' destination email addresses. The database comprises a list 
10 of destination email addresses associated with each user. The database may further comprise 
device type data associated with each destination email address. This additional information 
may be used to determine whether or not the device type is compatible with the user's 
instructions. In this embodiment, if the device is not compatible, the system may modify the 
user's instruction according to the device type. 
15 It is an object of the present invention to provide a system and method for remotely 

managing email messages on an email server using a remote email account. 

It is another object of the present invention to enable users to remotely manage email 
messages on an email server using a remote email account with a standard email client interface. 

It is another object of the present invention to allow an email user to retrieve email from 
20 one email account to a remote email account. 

These and other objects of the present invention are described in greater detail in the 
detailed description of the invention, the appended drawings and the attached claims. 
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DESCRIPTION OF THE DRAWINGS 

Figure 1 is a schematic diagram of a network architecture in which the present invention 
may be implemented. 

Figure 2 is a functional diagram showing data flow and programming logic used in a 
preferred embodiment of the present invention. 

Figure 3 a is a flow chart of steps carried out in a preferred embodiment of the present 
invention. 

Figure 3b is a flow chart of steps carried out in an alternative embodiment of the present 
invention. 

DETAILED DESCRIPTION OF THE INVENTION 

The present invention may be implemented in any network email architecture, such as, 
e.g., the architecture shown in Figure 1. In a preferred embodiment, only the email server 
application on selected email hosts need be modified or supplemented with programming logic 
and databases according to the present invention. That is, only email server applications 
allowing remote email management need the additional programming logic. The remote email 
server applications and associated client application do not need any changes to operate in 
accordance with the present invention. In an altemative embodiment, the email client 
applications used by subscribers to issue instruction email messages may be modified or 
supplemented as described herein. 

For purpose of explanation, assume a user (not shovra in Figure 1) has email accounts on 
each of the hosts and networks described above. That is, assume the user's email addresses for 
the respective networks are as shown in Table 1, below. Assume, fiorther for purposes of the 
present example, that the user wishes to manage email on email hosts 12, 22 or 52 via remote 



email accounts accessible via mobile telephone 34, PDA 36 or interactive pager 44, In this case, 
the email server applications running on email hosts 12, 22 and 52 are referred to herein as 
"source server applications" and the user's accounts on wireless network 30 and interactive 
paging network 40 are referred to herein as "destination addresses." 



NETWORK 



Internet Email Network 10 
ISP Network 20 
Wireless Network 30 
Interactive Paging Network 40 
Private Network 50 



EMAIL ADDRESS 



John,Doe@emailhostl 2.com 
john@emailhost22.net 
jdoe@emailhost32.wireless.com 
jdoe@emailhost42.paging,net 
John Doe@emailho$t52.work.com 



Table 1 

3 In the preferred embodiment, the present invention is implemented by adding 

^ programming logic to the source server application. For example, the source server applications 
I running on email hosts 12, 22 and 52 would include programming logic for interpreting 
10 instructions from authorized users and acting accordingly. Email hosts 32 and 42 could also 
y include the programming logic for interpreters such instructions if the user wishes to remotely 
3 manage email on accounts in those networks. 

Figure 2 shows a schematic diagram of a source application server and the programming 
logic added in the preferred embodiment of the present invention. As shown in Figure 2, the 
15 programming logic comprises a plurality of program modules. The modules may be external 
applications called by email application server 200 as shown in Figure 2, or alternatively, one or 
more of the modules may be integral to application server 200. The modules in the preferred 
embodiment include registration module 210, instruction module 220 and action module 230. 
As shown in Figure 2, registration module 210 and instruction module 220 each interfaces with a 
20 database. Although databases 2 1 2 and 222 are shown as different databases, they could 
comprise a single database storing the information needed to carryout the present invention. 
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Moreover, the information may be integral to the modules or email server application 200, in 
which case no separate database is required. 

Registration module 210 uses database 212 to store user registration information. 
Registration information may comprise a list of valid destination addresses for each user and 
5 may further include a password selected by the user for access control. User registration 
information may be transmitted to registration module 210 using any suitable means. For 
example, the requests may be provided via an interactive form submitted using a web browser 
interface. Alternatively, the requests may be provided via email from the user. The request 
3 could even be manually entered by a technician upon oral or written request by the user. The 
4lO registration module may also provide any user interface features desirable for allowing users to 
identify all destination addresses that from which the user may manage his or her email 
according to the present invention. 

In the present example, because the user wishes to remotely manage accounts from 
y wireless network 30 and paging network 40, the user's email addresses on those networks must 
31 5 be registered in the source server applications. That is, the user would register destination 

addressesjdoe@emailhost32.wireless.com andjdoe@emailhost42.paging.net via a registration 
module on email hosts 12, 22 and 52. By registering a destination address on a source server, the 
user authorizes the source server application to accept email management instructions received 
from the destination address. For example, if the user wishes to retrieve email from his or her 
20 private network account to his or her interactive pager account, the user must register the address 
jdoe@emailhost42.paging.net on email host 52. To request retrieval of the email, the user sends 
an email message from interactive pager 44 to email host 52 as described below. 
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User management instructions are sent via email messages from the destination address 
to the source server. In one embodiment, the user's email message includes a special code in a 
predetermined field to identify the email message as a request for remote management by the 
user. In this case, when the source server receives incoming email message it checks the 
predetermined field for the special code. If the code is present in the predetermined field, the 
email message is passed to instruction module 220 for further processing. For example the 
special code may be a particular character string, such as, e.g., or "*MANAGE EMAIL*" or 
some other string or symbol which flags an incoming email message for special processing. The 
predetermined field could be any of the fields comprising an email message. Preferably, the 
predetermined field is either the subject field or the email message body. In an alternative 
embodiment, the user addresses the email to a special account on the source server. In this case, 
all email addressed to the special account is passed on to instruction module 220 for processing 
In either case, instruction module 220 or email application server 200 consult with registration 
module 210 and database 212 to verify that the sender of the email message is authorized to 
remotely manage an email account. If the sender is authorized, i.e., if the email message was 
received from a registered destination email address, instruction module 220 parses the message 
to determine the appropriate instructions. In the sender is not authorized, then no further action 
need be taken by the system of the present invention. The system may optionally send an error 
message in reply to the received email message to inform the sender of the problem. 

The user's instructions are inserted in the email in a predefined format. For example, the 
instructions may inserted into the email subject field and may include a command and a criteria. 
The command identifies the actual email management instructions the user wishes to perform 
and the criteria identifies the email messages to be acted on. In a preferred embodiment, if no 
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criteria is provided, the command performed on all of the user's email on the source server. 
Also, in a preferred embodiment, the command may blank, which may indicate some default 
command, such as retrieve, should be executed. 

In a preferred embodiment, the commands include management operations such as send; 
delete; forward (to another account); send without attachments, send only attachments; move (to 
a folder or directory on the source server); print; and the like. Also in the preferred embodiment, 
multiple commands may be issues in a single email messages. For example, the user may 
instruct the source server to send the user's email to the destination address, then delete the email 
from the user's mailbox on the source server. The criteria used to identify email messages may 
include a boolean operation, such as, e.g., "DATE > YESTERDAY" (all email received since 
yesterday); "FROM = jane.doe@home.com" (all email received from the address 
jane.doe@home.com), or "DATE - 21-jun-2000 and SUBJ o 'important document'" (all email 
received on the date, June 21, 2000 and containing the phrase "important document" in the 
subject field). The criteria need not be boolean-based, that is, any suitable syntax may be used to 
allow the user to identify a particular email message or class of email messages to be managed 
according to the system and method of the present invention. Moreover, the email messages to 
be managed could even include email in the user's "outbox," i.e., the criteria could allow the user 
to identify email messages sent by the user from the source server. Instruction module may 
consult database 222 for valid boolean operators and fields which may be operated upon. 
Database 222 may also comprise the user's email account (i.e., the user's inbox and outbox). 

After instruction module 220 determines the user's management commands and identifies 
the email messages to be operated on, action module 230 in invoked. As shown in Figure 2, 
either instruction module 220 or email server application 200 may invoke action module 230. 
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Action module 230 prepares the selected email messages according to the user's instructions. 
For example, action module 230 may instruct email application server 230 to forward the 
selected email to the destination address. In a preferred embodiment, action module 230 further 
formats the email messages for easy identification at the destination address. For example, 
action module 230 may modify the subject field of the message to indicate the true sender's 
name. Such modification is useful because the message sent to the destination address will have 
a new sender, such as the user's account on the source server or some other account on the 
source server. By modifying the subject field, the user can identify the message's original 
sender. Similarly, the subject field could be modified to include the criteria provided by the user 
in the email instruction message. Again, such modification would assist the user in identifying 
the email once it is received at the destination address. 

Registration database 212 may further comprise a list of device types and associated 
device capabilities for each registered destination email addresses. Such information can be used 
to validate instructions sent by the user. For example, database 212 may include an annotation 
that wireless telephone 34 does not have the capability to receive binary attachments. 
Accordingly, if the user sends an instruction that would otherwise result in a binary attachment 
being transmitted to wireless telephone 34, instruction module 220 or action module 230 may 
consult database 212 to determine whether or not the action should be taken. 

In another alternative embodiment, registration database 212 may comprise a password or 
personal identification number ("PIN"). In this embodiment, tiie user is not limited to using only 
registered destination email addresses for remotely managing email on the source server. That 
is, the user may send an email instruction from any email account, provided that the instruction 
email includes the password or PIN. Preferably, the instruction email is encrypted by the user to 
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protect the password or PIN. If the email is encrypted, the email server application includes the 
key needed to decrypt the email for further processing. 

The present invention may further comprise programming logic added to an email client 
application. Such programming logic includes a user-friendly interface for constructing email 
instruction messages according to the present invention. Accordingly, a user need not 
memorized or use a complex syntax for identifying the email messages to be managed. 
Moreover, the user need not know the command structure required by the instruction module on 
the email application server-side. 

The flow charts in Figures 3a and 3b show the steps implemented in an embodiment of 
the present invention. In Figure 3a, the email server application accepts email messages directed 
to a special account setup to receive email instructions according to the preferred embodiment of 
the present invention. In contrast, the flow chart in Figure 3b shows email server application 
implemented using the alternative embodiment of checking incoming email for the special code 
in some predetermined field, such as the subject field of the message. 

In step 300, an email message is received by an email server application (for example 
email server application 200 shown in Figure 2) on an email host, such as email host 52 in 
private network 50. In step 310, the system determines if the email message is addressed to the 
special account for handling according to the present invention. If the email is not addressed to 
the special account, the message is processed according to normal email channels and the system 
and method of the present invention ends processing. If the email message is addressed to the 
special account, step 320 is performed. In step 320, registration database 212 is checked to 
determine whether or not the sender of the email is a registered destination email address. Step 
320 may be performed directly by email server application 200 or by instruction module 220 or 
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even registration module 210. As shown in figure 3a, if the sender is registered, the system 
moves on to step 330. If the sender is not a registered destination email address, the system may 
perform optional step 335 and check the email message to see if a valid PIN or password is 
included. If a PIN or password is included in the message it is checked against database 212 for 
validity. If the PIN or password is not valid, the system exits. In an alternative embodiment, an 
additional step may be included such that an error message is sent to the sender of the email. If 
the PIN or password is valid, the system moves on to step 330. 

In step 330, instruction module 220 parses the email message to determine the user's 
instructions for remotely managing email on the source server. As described above, the 
instruction may comprise a plurality of commands and a plurality of criteria for selecting email 
messages to be managed. In step 330, instruction module ensures that the instruction is valid and 
can be performed as requested. If the instruction is not valid, the system may attempt to fix the 
instruction in optional step 345. If the user's instructions cannot be fixed, the system may move 
on to optional step 347, where the user is sent a reply message. If optional step 345 is 
implemented in an embodiment of the present invention, the fixed instruction preferably is non- 
invasive, that is, the system will not destroy email messages on the source server without express 
instructions from the user. As described above, a situation where the system could fix the 
instruction may arise if database 212 also includes device type information associated witii each 
destination email address. In tiiis case, if the user requests attachments to be sent, but the device 
cannot receive such input, tiie user's instruction may be modified to send only the main part of 
the email but no attachments. Similarly, the user's instruction may be modified to instead send 
an error or otiier informational message to the user. 
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If the user's instruction is valid or is fixed in step 345, the system moves on to step 350 
for further processing according to the present invention. In step 350, the user's instructions are 
processed by action module 230. As described above, actions taken may include a number of 
email management tasks. For example, the action may be to send selected email messages to the 
user followed by deleting the email from the user's inbox. 

The flow chart in Figure 3b shows many of the same steps described above. For 
simplicity, optional steps, such as steps 345 and 347, are omitted from Figure 3b. However, 
these optional steps and others may be included in this embodiment if desired. The primary 
difference between the embodiment shown in Figure 3b and that shown in Figure 3a, is how the 
system determines that an email received by the email server application comprises a request for 
remote management from a user. As shown in Figure 3b, step 310 (determining that the email is 
sent to a special account) is replaced by step 315. In step 3 1 5, a predetermined field of the email 
message is checked for a special code. In a preferred embodiment, the predetermined field is the 
subject field and the special code is comprises a character or string of characters not commonly 
included in a subject field. The code may also comprise the users instructions for remote 
management. The remaining steps shown in Figure 3b are the same as shown in Figure 3a. 

The foregoing disclosure of embodiments of the present invention has been presented for 
purposes of illustration and description. It is not intended to be exhaustive or to limit the 
invention to the precise forms disclosed. Many variations and modifications of the embodunents 
described herein will be obvious to one of ordinary skill in the art in hght of the above 
disclosure. The scope of the invention is to be defined only by the claims appended hereto, and 
by their equivalents. 
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